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(54) System and method for private and secure financial transactions 



(57) A system and method for private and secure fi- 
nancial transactions. The system and method comprise 
embedded into financial institutions (financial 
institution ) privacy and security layer architecture and 
the "clocked" authentication, authorization and account- 
ing (AAA) method. The system and method enable legal 
financial account holders (financial account holder) to 
perform buy/sell or withdraw/deposit financial transac- 
tions (financial transaction ) without disclosing private 
personal information to the transaction counterparts, 
while preserving highly elevated and enhanced security 
and fraud protection as compared with conventional 
methods. Before financial transaction, financial account 
holder initiates an authentication session with financial 
institution back office (financial institution back office) by 
accessing its central processing unit (CPU) and data 
base (dB), configured in the embedded privacy and se- 
curity layer (EPSL) architecture with automated 
"clocked" AAA sessions by using dedicated communi- 
cation lines. The authentication session is interactive, 
transaction specific and followed by either financial 



transaction deny or an alphanumeric signature gener- 
ated for this specific financial transaction . Then finan- 
cial account holder submits his/her request to a trans- 
action counterpart along with the EPSL account number 
and the alphanumeric signature, generated by financial 
institution EPSL during previous authentication session. 
The transaction counterpart adds up additional or more 
refined financial transaction specific information and re- 
quests an authorization session with financial institution 
back office where the EPSL account, CPU and dB are 
residing. The accounting session starts at the end of the 
authentication session and finishes along with the au- 
thorization session while being an essential part of them 
both. The system and method are particularly suited for 
use by banks, credit card companies and brokerage 
companies. Finally, the system and method are well 
adapted to the current and upcoming software, hard- 
ware, and electronic commerce technologies and can 
be easily implemented given an acceptable business 
trade off. 
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Description 

BACKGROUND OF THE INVENTION 
Field of the Invention 

[0001] The present invention relates to a system and 
method for private and secure transactions and more 
particularly to a system and method for providing private 
and secure buy/sell or withdraw/deposit transaction en- 
vironment within financial institutions and at merchants 
/ sellers / vendors transaction-processing systems. 

Description of the Related Art 

[0002] Basic financial transactions including buy/sell 
and withdraw/deposit, have always required security to 
protect the financial account holder, the financial insti- 
tution where the account resides, and a merchant/seller/ 
vendor or other party at the point of sale from identity 
theft and fraudulent transactions. Due to wide spread 
use of computer networks and electronic commerce as 
a new medium to perform transactions, new require- 
ments to maintain validity and integrity of financial trans- 
actions are arising. There are companies gathering, 
sorting, researching and selling for profit consumers' pri- 
vate personal information acquired during financial 
transactions. It would be advantageous to provide an 
efficient system and method to protect customers' pri- 
vacy during financial transactions. Another new require- 
ment is associated with the fact that hackers and intrud- 
ers getting an illegal access to the computer network 
can compromise financial transactions. This aspect of 
transactions' security is addressed in U.S. Pat. No. 
6,092,202 to Veil et al. 

[0003] Throughout the entire history of financial trans- 
actions, privacy and security were addressed by the 
best contemporary technologies. Since the onset of the 
computer network era, computer power, relational data- 
bases, software environments and communication lines 
have been used by financial institutions for security and 
privacy functions. Banks, then credit card companies 
and eventually brokerage companies and other financial 
institutions have used them to perform authentication, 
authorization and accounting, referred to as AAA, at 
their back offices during financial transactions. 
[0004] Financial transactions with credit cards suffer 
significant losses due to weaknesses in implementing 
the authentication stage of financial transaction. A party 
at the point of sale compares human signatures visually 
on a card (if there is any) and on a selling slip. This op- 
eration is error prone when identifying faked signatures 
in a case of fraudulent actions. If a financial account 
holder loses an unsigned credit card it is easy to fake 
signatures as one can place any signature on a card 
before requesting a financial transaction. Another typi- 
cal malfunction at the authentication stage of financial 
transaction occurs when someone gets a credit card ac- 



count number and a copy of the card owner's signature. 
This enables fraud even with non-stolen credit cards. 
Another example where financial institutions incur loss- 
es is caused by financial account holders, when they 
5 change their minds after concluding a financial transac- 
tion. A financial account holder can repudiate the finan- 
cial transaction by claiming that somebody transacted 
in his or her place. 

[0005] These examples show that there is a real and 
10 substantial need for an improved financial transaction 
architecture at the authentication stage of financial 
transaction. The fact that mistakes in authenticating 
non-real credit card owners followed by successful au- 
thorization and accounting sessions at financial institu- 
15 tion back offices illustrate another weakness of the fi- 
nancial transaction architecture. Authorization and ac- 
counting stages are de-coupled from the actual financial 
account holder, while the authentication stages are de- 
coupled from financial institution back office computers. 
20 [0006] Though credit cards have been used as a fi- 
nancial transaction instruments since the beginning of 
electronic commerce, there is number of issues in ar- 
chitecture that have become apparent. For instance, 
credit card data, a social security number, a card holder 
25 name, phone, address etc., while transferred through 
the Internet, are not absolutely secure and can fall into 
"wrong hands" due to communication channel leaks. It 
is obvious that while high speed data flow through the 
Internet or other communication channels is a big ad- 
30 vantage for financial transactions, insufficient data se- 
curity makes it highly desirable to alter the financial 
transaction architecture to avoid potential data leaks on 
communication lines (Internet and non-Internet as well). 
[0007] Another issue jeopardizing financial transac- 
ts tions in electronic commerce is weakness of the author- 
ization stage of financial transactions with credit cards. 
Neitherthe authorization stage northe accounting stage 
are actively controlled and timed by financial account 
holders. Numbers of non-requested sell transactions 
40 may happen before a financial account holder regains 
control on his/her account. U.S. Pat. No. 5,485,510 to 
Colbert and U.S. Pat. No. 6,052,675 to Checchio dis- 
closed attempts to improve the authorization stage of 
financial transactions in order to enhance financial 
45 transaction security. The Colbert patent proposed to al- 
ter financial transactions by authorizing a financial ac- 
count holder before he/she applies to a merchant (a ven- 
dor). Information supplied to financial institution back of- 
fice includes a credit card account number, a secret PIN 
50 and merchant /financial transaction specific information 
(at least, merchant ID number and financial transaction 
amount). Then the merchant is given only the authori- 
zation code, while the card number and the PIN remain 
unknown to the merchant or anybody, if the card is lost 
55 or stolen. Similar architecture is offered in the Checchio 
patent, except a merchant does not get any authoriza- 
tion code, but rather a credit card account number. Since 
the financial transaction is pre-authorized in this case, 
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a merchant sends into the financial institution back office 
a credit card account number and merchant / financial 
transaction specific information which is compared with 
data given by the financial account holder during the 
pre-authorization stage. Neither a merchant nor any- 
body can use the card without knowing a secret PIN, if 
it is lost or stolen. 

[0008] Though both patents allow improve security 
against fraudulent usage of credit cards for certain types 
of transactions, there are limitations to be addressed. 
Both patents are centered on phone lines, when com- 
municating to financial institution back offices. Frequent 
usage of a pair of static numbers over phone lines is 
insecure due to leaks at the line entries and on the lines 
themselves. This issue gets aggravated, if one would 
like to replace phone lines by wireless or the Internet 
communication lines. Another weakness common to 
both patents is lack of a system and / or method as to 
how the financial institution back office is supposed to 
handle proposed architectural changes for mass finan- 
cial transactions. Financial transaction architectures 
ought to cover financial account holders, financial insti- 
tutions and a party at the point of sale in a mutually de- 
pendent way. A necessity to have prior to the authoriza- 
tion stage knowledge of a party at the point of sale and 
other financial transaction specifics is an additional lim- 
itation in both proposed innovations. That narrows down 
types of possible financial transactions and locations, in 
which they can be performed from. 
[0009] There is a public concern that financial trans- 
actions with credit cards either in electronic commerce 
channels or in other traditional channels could lead to 
private personal consumers' information being ac- 
cessed, monitored, tracked, stolen and fraudulently 
used or sold for profit often without the consumers' ap- 
proval. Privacy related problems are exacerbated with 
the advanced Internet related technologies due to the 
ease with which information can be collected, proc- 
essed and combined with other information. 
[0010] It is not only financial transactions with credit 
cards which raise numerous privacy issues. Even during 
standard withdraw/deposit financial transactions at a 
bank, a financial account holder would not always like 
a bank teller to have access to his/her private personal 
information file. It would be beneficial if a financial ac- 
count holder could decide whether this privilege should 
be given to the bank teller. More often than not, with- 
draw/deposit financial transactions at a bank require fi- 
nancial account holder identification documents to be 
revealed, which can be viewed as a certain privacy re- 
lated inconvenience justified by the current state of the 
authentication architecture during financial transaction. 
[0011] FIG. 1A illustrates a block diagram of a con- 
ventional system for performing withdraw / deposit 
transactions. In order to perform financial transactions, 
a legal adult 101 (or a legal business) is supposed to 
have an account with a financial institution. It is standard 
to disclose a private, personal information profile 102 to 
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the financial institution during the account application 
process. At step 104, the financial institution, which per- 
mitted an account opening, creates a personal log file 
in the financial institution back office, establishes a with- 
draw / deposit mechanism, and issues personal checks 
and cards. Then financial account holder, whether it is 
a legal person 101 or a legal business, can perform de- 
posit 105 or withdraw 106 transactions. Typical deposit 
transactions to a bank or a brokerage house 107 are 
made through either a direct / mailed deposit with a per- 
sonalized deposit slip 109 or by submitting a check on 
one's name and disclosing one's account number. An- 
other way of obtaining deposits is used by insurance 117 
and credit card companies 115, which receive paid 
statements 119 from financial account holder. Checks 
110, debit cards 112 or Graphical User Interfaces (GUI) 
over the Internet 113 are used by financial account hold- 
ers for withdraw transactions with a bank or a brokerage 
house 108. The credit card 116 is a typical withdraw 
mechanism for withdraw transactions with credit card 
companies (whether they are banks like Visa and Mas-, 
ter Card or not, like American Express). Another with- 
draw mechanism is used by financial account holders 
when dealing with insurance companies 1 1 8. A request 
for payment 120 is to be made in accordance with the 
insurance policy. ™: 
[001 2] There are deficiencies in the deposit / withdraw 
transaction system described above related to privacy 
and security of the financial account holder and financial 
institution performing transactions including the follow- 
ing: 

1) Direct and urgent deposit transactions can be 
hindered, if the financial account holder is located 
far away from the bank and its branches where the 
account resides. It should be possible to deposit to 
one's account via otherfinancial institutions, without 
disclosing private personal information of financial 
account holders at other financial institution's inter- 
mediate service levels. 

2) During depositing, bank tellers get access to the 
private personal information of thefinancial account 
holder. There are two issues here. Firstly, a teller 
can make mistakes altering personal and account 
balance information without any immediate finan- 
cial institution back office CPU and dB control. In 
other words, each deposit transaction has a proba- 
bility of mistakes, hurting the bank and the financial 
account holder. Secondly, the financial account 
holder may not like a bank teller to have access to 
his / her private persona! information file during di- 
rect depositing. At this stage it would be beneficial, 
if financial account holder could decide him- / her- 
self whether this privilege should be given to the 
bank teller. 

3) Insufficient theft and fraud protection during with- 



BNSDOCIO <EP 1223524A2J 



5 



EP 1 223 524 A2 6 



draw transactions with checks, credit, charge and 
debit cards or during electronic commerce financial 
transactions. 

4) Private personal information is not protected and 
often intentionally or unintentionally misused by a 
party at the point of sale or bank tellers during with- 
draw transactions. 

[0013] FIG. 1B illustrates a block diagram of a con- 
ventional system for performing buy / sell transactions. 
Once financial account holder 121, has made a buying 
decision 1 22 and applied to a party at the point of sale, 
the actual selling transaction is enabled through cash 
124, credit cards 116, debit cards 112, checks 110 or 
electronic commerce 125. Though cash is handy for low 
value financial transactions, it is usually impractical for 
the bulk of mass financial transactions due to low cash 
amount on hand. All other financial transaction instru- 
ments except cash, such as credit cards 116, debit cards 
112, electronic commerce 125 and checks 110 lead to 
either complete or partial disclosure of private personal 
information 127, and are therefore prone to private per- 
sonal information misuse and fraudulent actions 128. 
[0014] FIG. 2 illustrates a block diagram of a conven- 
tional system and method for performing authentication, 
authorization and accounting sessions during buy / sell 
transactions with a credit card, a charge card or a debit 
card. As illustrated in FIG. 1 B and FIG. 2, once a finan- 
cial account holder 121 has made a buying decision 1 22 
and applied to a party at the point of sale, a point-of-sale 
(POS) device scans static information on a credit card 
and sends an authorization request to financial institu- 
tion back office, specifying price (money transaction 
amount), to perform a withdraw transaction 205. The fi- 
nancial institution back office CPU checks whether there 
is enough money in the database underthis account and 
if yes, and if the card is not marked in the database as 
lost, stolen orfraudulently used, authorizes the withdraw 
transaction 206 (it sends an authorization code to POS 
device). Steps 205 and 206 constitute the authorization 
stage 201 of the financial transaction. It is worthwhile to 
note that in the conventional financial transaction sys- 
tem with credit / debit cards, the authorization stage is 
performed priorto authentication and accounting stages 
of the financial transaction. 

[001 5] Once the transaction authorization is sent to a 
party at the point of sale 206, the first accounting step 
202 is performed. The account under transaction is left 
with a locked sum of money to assure a payment to a 
party at the point of sale 207. The payment is made after 
deduction of the transaction fee to the card issuing bank 
and the discount rate fee to the acquiring bank or an 
independent sales organization, which provided the 
merchant status to a party at the point of sale. Once step 
207 is completed, the financial institution back office is 
ready for another transaction of the same financial ac- 
count holder, provided the requested spending limit is 



not exceeded. 

[0016] Then if the credit card is signed, the signatures 
on the selling draft and on the card are visually com- 
pared at a party at the point of sale for off line financial 

5 transactions 208. If the card is not signed, identification 
documents are requested from financial account holder 
209. Steps 208 and 209 are components of the authen- 
tication stage of financial transaction 203 for the con- 
ventional off line financial transaction system. It can be 

10 noted here that the conventional electronic commerce 
on line financial transaction system based on credit / 
debit card usage skips step 208, and instead enforces 
step 209, requiring quite wider disclosure, than in a case 
of off line financial transaction, of financial account hold- 

15 er private personal information. Then the final step of 
accounting stage 204 is performed. Step 210 includes 
the following: a party atthe point of sale sends the selling 
draft inside the selling batch after trade hours to the ac- 
quiring bank (or an independent sales organization). 

20 The acquiring bank re-routes the respective part of the 
batch to the card issuing bank to unlock the payment 
and transfer it to a merchant account after deductions, 
specified in the merchant's agreement. Then the money 
is placed into a merchant account in few days. 

25 [0017] The conventional financial transaction archi- 
tecture based, on credit / debit cards and shown in FIG. 
2 has the following weaknesses, which the present in- 
vention addresses: 

30 1 ) Authentication stage is de-coupled from financial 
institution back office CPU and dB, making it sub- 
jective, embarrassing, error and fraud prone. 

2) Authorization stage is de-coupled from financial 
35 account holder for both on and off line financial 

transactions, making it especially dangerous for on 
line financial transactions (due to on line financial 
transaction latency, a number of unauthorized fi- 
nancial transactions may happen before financial 
40 account holder regains control on the account). 

3) Private personal information leaks are possible 
on the Internet communication lines during elec- 
tronic commerce sessions (browsing technology, 

45 TCP/IP protocols, PKI, SSL and other Internet tech- 
nologies do not guarantee sufficient financial trans- 
action security). 

4) Accounting stage is de-coupled from financial ac- 
50 count holder, keeping one at inconvenience during 

a series of buy / sell financial transactions. 

5) A party at the point of sale may collect and ana- 
lyze financial account holder private personal infor- 

55 mation, and market and sell it for profit. This leaves 
public at large unaware of privacy and confidential- 
ity status of the data. 
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[0018] Present on line and off line financial transac- 
tion architectures have substantial security and privacy 
deficiencies at the authentication, authorization and ac- 
counting stages. It would be highly desirable to provide 
an improved system and method wherein consumers 
can perform financial transactions with financial institu- 
tions without privacy and security concerns. The present 
invention addresses these problems. 

SUMMARY OF THE INVENTION 

[001 9] It is therefore an object of the present invention 
to cut off merchants / sellers / vendors from consumers' 
private personal information during financial transac- 
tions. 

[0020] A further object of the present invention is to 
allow a financial account holder to cut off bank tellers 
from their private personal files during withdraw/deposit 
transactions. 

[0021] A further object of the present invention is to 
provide a method, which couples together a financial ac- 
count holder and a financial institution back office during 
the authentication stage of financial transaction to in- 
sure highly elevated and enhanced security of financial 
transactions. 

[0022] A further object of the present invention is to 
create the authentication stage architecture of financial 
transactions, which makes the authentication stage of 
financial transactions a transaction specific one; e.g. it 
can be used just only for one particular financial trans- 
action. 

[0023] A further object of the present invention is to 
include the beginning of the accounting session of a fi- 
nancial transaction into the authentication stage archi- 
tecture of financial transaction to enhance transaction 
specific authentication architecture. 
[0024] A further object of the present invention is to 
architect a financial transaction authentication session 
in a way that makes a positive authentication outcome 
a time specific one for a particular financial transaction. 
[0025] A further object of the present invention is to 
design a system and to provide a method for financial 
transactions that enables merchants / sellers / vendors 
to request financial institution back offices to authorize 
and to account financial transaction just for one partic- 
ular financial transaction requested by financial account 
holder. 

[0026] . A further object of the present invention is to 
include the end of the accounting session into the au- 
thorization stage architecture of financial transaction. 
[0027] A further object of the present invention is to 
create financial transaction architecture that provide a 
high security level even in an environment with possible 
leaks on communication lines due to incomplete secu- 
rity of such Internet technologies as SSL (Secure Socket 
Layer), TCP/IP protocol, WEB browsers etc. 
[0028] A further object of the present invention is to 
provide "clocked" AAA for financial institution back of- 
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fices that allows implementation of financial transaction 
specific AAA architectures. 

[0029] The present invention is a system and method 
for providing private and secure financial transactions. 
5 The system and method, comprise a "clocked" AAA 
method embedded into financial institution back office 
privacy layer architectures. The architecture comprises 
"back office connection devices" for use by financial ac- 
count holders to connect to financial institution back of- 
10 fices. Such devices include for example regular phones, 
and personal computers with a specific Graphical User 
Interface (GUI) invoked through a Universal Resource 
Locator (URL) address. Alternatives include network 
computers or wireless personal organizers, interactive 
*5 TV set sessions or smart cards with customized read / 
write devices to interact with financial institution back 
offices. The architecture comprises also a financial in- 
stitution back office central processing unit ("the CPU"), 
which could include a farm (or cluster) of compute and 

20 file servers operated under either UNIX Sun/Solaris or 
Windows NT operating system; a number of software 
programs (software modules) designed to implement 
various functions of "clocked" AAA; a relational data- 
base (dB) inside financial institution back offices, where 

25 the actual account information is stored and accessed. 
The financial institution back office include's'a dB con- 
nected to the CPU where information is processed using 
the "clocked" AAA program environment. 
[0030] The present invention allows consumers hav- 

30 jng membership with any financial institution to perform 
financial transactions in a highly secure and private 
manner. Financial account holder private personal infor- 
mation need not be disclosed to a party at the point of 
sale nor a bank teller. Finally, the system and method 

35 are well adapted to the current and upcoming software, 
hardware and electronic commerce technologies and 
can be easily implemented given an acceptable busi- 
ness trade off. 

[0031] A method for managing financial transactions 

40 according to the present invention includes performing 
an authentication process, an authorization process and 
an accounting process. The authentication process is 
executed for a predicted transaction by a particular ac- 
count holder. The predicted transaction has a predicted 

45 transaction amount and a predicted transaction time. 
The authentication process produces a transaction sig- 
nature for presentation upon execution of the predicted 
transaction. The authorization process for a particular 
transaction has an actual transaction amount and an ac- 

50 tual transaction time which are determined upon pres- 
entation of the transaction signature. The authorization 
process includes verifying that the presented transac- 
tion signature matches the transaction signature for the 
predicted transaction; that the actual transaction 

55 amount matches the predicted transaction amount, and 
that the actual transaction time matches the predicted 
transaction time. The accounting process for the partic- 
ular transaction is performed as a result of a successful 
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authorization process. The accounting process includes 
reconciling the predicted transaction amount and actual 
transaction amount for the particular account holder. 
[0032] According to one embodiment of the invention, 
the predicted transaction amount and the transaction 
signature for a predicted transaction are stored in an au- 
thentication record in a database at the financial institu- 
tion back office. Likewise, an authorization record is cre- 
ated during the authorization process. The authorization 
record and the authentication record are compared to 
complete the authorization process for the transaction. 
Thus, the authentication record includes the predicted 
transaction amount and the transaction signature. Also, 
a predicted transaction time is stored in the database 
which holds the authentication record, as for example, 
a time out interval length used in combination with a time 
of creation of the authentication record, or for another 
example, as an absolute time value. 
[0033] One representative embodiment of the au- 
thentication process includes establishing a communi- 
cation session between the particular account holder 
and the financial transaction server, accepting an ac- 
count number as input, prompting the particular account 
holder to supply a static identification number at a first 
instance, and a dynamically identified combination of 
digits from personal identification code, where in the 
combination does not include all the personal identifica- 
tion code, at a second instance. Further, the predicted 
transaction amount is accepted as input. The transac- 
tion signature is produced and sent to the particular ac- 
count holder. The information identifying the predicted 
transaction, and the time stamp are stored in an authen- 
tication record. 

[0034] A representative embodiment of the authoriza- 
tion process includes establishing a communication 
session between a party to the particular transaction 
and a financial transaction server. At the server, a pre- 
sented transaction signature is accepted and an actual 
transaction amount is received as inputs. The server 
compares the time of the particular transaction with the 
predicted time, and the presented transaction signature 
and the actual transaction amount with the predicted 
transaction amount and the transaction signature asso- 
ciated with the transaction. An authorization message 
is sent to the party to the transaction upon successful 
matching of the parameters. 

[0035] The process for managing financial transac- 
tions according to present invention works with or with- 
out identification of the financial account holder during 
the authorization process. 

[0036] In various embodiments, the present invention 
comprises a system which executes the authentication 
process, the authorization process, and the accounting 
process utilizing communication media interconnecting 
the financial institution back office with individual end 
stations, such as cell phones, point-of-sale devices, per- 
sonal computers, handheld computers, and the like. In 
an alternative embodiment, the present invention corn- 
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prises an article of manufacture storing computer pro- 
grams used for executing the processes as outlined 
above. 

[0037] In yet other embodiment, the present invention 
5 provides a financial transaction server including com- 
munication resources, processing resources, and data 
storage resources utilized for managing the processes 
described above. 

[0038] The present invention also provides a method 
10 for automated authentication, authorization and ac- 
counting for financial transactions. The method com- 
prises establishing an authentication record for a pre- 
dicted transaction by a particular account holder. The 
authentication record includes information identifying a 
is predicted transaction having a predicted transaction 
amount and a transaction time parameter. Also, an au- 
thenticated transaction signature for presentation upon 
execution of the predicted transaction is included in the 
authentication record. The method also comprises es- 
20 tablishing authorization record for a particular transac- 
tion indicating an actual transaction amount, an actual 
transaction time and a presented transaction signature. 
The authorization record and the authentication record 
are matched to determine whether the presented trans- 
25 action signature matches the authenticated transaction 
signature for the predicted transaction, whether the ac- 
tual transaction amount matches the predicted transac- 
tion amount, and whether the actual transaction time 
matches the transaction time parameter. Finally, the 
30 predicted transaction amount and actual transaction 
amount are reconciled for the particular account holder. 
According to various embodiments, the method in- 
cludes storing the authentication record in a database 
including a plurality of authentication records for predict- 
35 ed transactions. The process involves periodically at- 
tempting to match authentication records with authori- 
zation records being created with a timed algorithm, 
which automatically times out authentication records 
based on their time of creation and a parameter deter- 
ge mining a length of time within which the predicted trans- 
action must be completed. 

[0039] In sum, a secure and private financial transac- 
tion process is provided that can be deployed efficiently 
and which addresses many of the deficiencies of other 
45 existing systems. 

[0040] Other aspects and advantages of the present 
invention can be seen on review of the drawings, the 
detailed description and the claims which follow. 

50 BRIEF DESCRIPTION OF THE DRAWINGS 

[0041] 

FIG. 1 A is a block diagram of a conventional system 
55 for performing withdraw/deposit transactions. 

FIG . 1 B is a block diagram of a conventional system 

for performing buy/sell transactions. 

FIG. 2 is a block diagram of a conventional system 
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and method for performing authentication, authori- 
zation and accounting sessions during buy/sell 
transactions with a credit card or a debit card. 
FIG. 3 is a flow diagram of the embedded privacy 
and security layer EPSL architecture for either buy/ 5 
sell or withdraw/deposit transactions. 
FIG. 4 is a flow diagram of the EPSL authentication 
session (while on financial account holder side). 
FIG. 5 is a flow diagram of the EPSL authentication 
session (while on financial institution back office io 
CPU and dB side). 

FIG. 6 is an interface protocol of the EPSL architec- 
ture. 

FIG. 7 is a flow diagram of the EPSL authorization 
session. is 
FIG. 8 is the EPSL transaction checklist. 
FIGS. 9A, 9B and 9C are a synthesis of a timing 
diagram, a flow chart and a functional diagram of 
the EPSL architecture based on the "clocked" AAA 
technology. 20 

DESCRIPTION OF PREFERRED EMBODIMENTS 

[0042] FIG. 3 shows a flow diagram of an embedded 
privacy and security layer EPSL architecture for buy / 25 
sell and withdraw / deposit transactions according to the 
present invention. Financial account holder 121 makes 
a transaction decision 122 irrespective whether it is go- 
ing to be on or off line financial transaction and inde- 
pendent of the point of sale (or a bank teller) locations. 30 
It is assumed at this stage that the financial account 
holder knows an approximate or exact amount of mon- 
ey, which will be required to perform the predicted finan- 
cial transaction. Following the transaction decision (step 
122), at step 301 , the financial account holder initiates 35 
an authentication session with a financial institution 
back office CPU and dB where financial account holder 
account resides. Details of how the authentication ses- 
sion is performed at financial institution back office ac- 
cording to present invention is described later. However, 40 
several features of step 301 are disclosed here. 
[0043] The financial account holder has to go through 
three tiers of financial institution back office security pro- 
tection, to initiate the authentication session. First two 
tiers are based on disclosing a financial institution EPSL 45 
account number and then a transaction (deposit or with- 
draw) static PIN secret number, which are intended to 
be known only^ro financial account holder and financial 
institution back office. Since the financial institution back 
office may be accessed by a financial account holder so 
through various dedicated communication lines, which 
have non-guaranteed security protection, a third secu- 
rity protection tier is included. The third tier is based on 
an interactive dialog between the financial institution 
back office and the financial account holder. The back 55 
office prompts the account holder to enter a random 
subset of digits particular to the given communication 
session of an identity PIN secret number, which is 



known only to financial account holder and financial in- 
stitution back office. The third security protection tier al- 
lows eliminating any potential information leaks at the 
entry devices and on the communication lines them- 
selves. Whoever intercepts the random digit combina- 
tion, requested during the third tier processing from fi- 
nancial account holder will not be able either reuse it or 
reengineer the entire identity PIN. 
[0044] Another feature of step 301 is that the financial 
institution back office prompts the financial account 
holder to enter the predicted transaction amount of mon- 
ey. Then, at the end of the authentication session 302, 
an alphanumeric transaction signature is generated at 
the financial institution back office 303 and transferred 
back to financial account holder. This signature is spe- 
cific to a particular financial transaction amount request- 
ed by financial account holder, and has a limited life 
time, set by default to a reasonable time interval suffi- 
cient enough to perform the financial transaction. It 
should also be noted here that the alphanumeric signa- 
ture can be used for only one financial transaction and 
can not be reused. 

[0045] Once the financial account holder is authenti- 
cated for a particular financial transaction , there is still 
room to back off from the financial transaction. To exe- 
cute the transaction, the financial account .holder sub- 
mits the alphanumeric transaction signature to a party 
at the point of sale (merchant or a bank teller) along with 
a financial institution EPSL account number. Neither the 
alphanumeric signature nor the financial institution 
EPSL account number contains any private personal in- 
formation, which could be associated with the financial 
account holder requesting a party at the point of sale to 
continue a financial transaction . At step 305 a party at 
the point of sale initiates an authorization session with 
financial institution back office CPU and dB. In addition 
to the alphanumeric transaction signature and financial 
institution EPSL account number given by the financial 
account holder, the party at the point of sale adds a busi- 
ness ID and an actual transaction amount of money and 
then sends this time stamped information sequence for 
authorization at financial institution back office. The de- 
tailed system and method to perform an authorization 
session at financial institution back office will be dis- 
cussed later. Information sent by the party at the point 
of sale (or a bank teller) for authorization is sufficient 
enough not only for an authorization session decision 
making process 306, but for accounting session com- 
pletion as well 307. At this moment, the financial trans- 
action is completed in a highly secure manner without 
disclosing financial account holder private personal in- 
formation to a party at the point of sale. 
[0046] The top level financial transaction architecture 
disclosed above is applicable to on and off line financial 
transactions. Though hardware and software environ- 
ments at the point of sale locations (like POS devices, 
GUI : selection of communication lines etc.) may vary for 
each of those two cases, the fundamental architecture 
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of private and secure financial transactions remains the 
same. The authentication stage, becomes the first per- 
formed step in the system and has paramount priority 
and security enforcement. It is not a party at the point 
of sale any more, who authenticates the financial ac- 
count holder, but the financial institution back office. It 
prevents fraud, embarrassment and private personal in- 
formation misuse by a party at the point of sale (or a 
bank teller). The financial account holder can not repu- 
diate the financial transaction, as nobody else could 
transact it in his or her place. The authorization and ac- 
counting stages of the financial transaction in the re- 
vealed system architecture can not occur without a prior 
request by the financial account holder. Thus, authori- 
zation and accounting are coupled with the actual finan- 
cial account holder, while authentication sessions be- 
came tightly coupled with the financial institution back 
office. 

[0047] FIG. 4 illustrates a flow diagram of the EPSL 
authentication session (from the financial account hold- 
er side). Basically, it is a more detailed flow diagram of 
steps 121 - 122 - 301 - 302 - 303 shown earlier in FIG. 
3, which all together constitute the authentication ses- 
sion for the financial account holder with the financial 
institution back office. The financial account holder is ex- 
pected to use various devices and communication lines 
to be able to reach financial institution back office. As 
illustrated in FIG. 4, example communication devices in- 
clude point of sale POS devices 401, conventional 
phone lines and mobile phones 402, network computers 
403 or wireless organizers 404 with URL / GUI capabil- 
ities and desktop personal computers connected to the 
Internet (or specialized financial institution on line serv- 
ices) 405. Once connection to the financial institution 
back office is established, the financial account holder 
is first requested to enter a financial institution EPSL ac- 
count number 406 (the first security tier). Then the finan- 
cial account holder is requested to enter a transaction 
type static PIN secret number 407 (the second security 
tier) and a requested random combination of digits from 
an identity PIN secret number 408 (the third security 
tier). Finally, the financial account holder enters an ex- 
pected transaction amount of money 409. A failure in 
making any of steps 406 - 407 - 408 - 409 leads to refusal 
by the financial institution back office to perform the au- 
thentication session. It is expected that the financial ac- 
count holder at this point will try again to initiate an au- 
thentication session or contact the financial institution 
EPSL representative after the second rejection 308. 
Successful completion of these steps ends up with an 
alphanumeric transaction specific signature generated 
at financial institution back office and transferred back 
to financial account holder 303. Step 409 is a last step 
in the authentication session, and it begins the account- 
ing session at financial institution back office. In this step 
409, the transaction amount of money requested by fi- 
nancial account holder is compared with an amount 
available in the account. The amount predicted should 



not be less than the actual amount specified later by a 
party at the point of sale (or a bank teller) during the 
authorization session request. It is important to note that 
step 303 will not be reached and the authentication 

5 stage at step 409 will be rejected, if the credit / debit 
financial institution EPSL card is listed at financial insti- 
tution back office as lost, stolen or fraudulently used. 
The authentication stage at step 409 will also be reject- 
ed, if the transaction amount of money requested by fi- 

10 nancial account holder exceeds available ones at finan- 
cial institution EPSL account. 

[0048] FIG. 5 shows a flow diagram of the EPSL au- 
thentication session (from the financial institution back 
office CPU and dB side). Due to a central position oc- 

15 cupied by an authentication session in the disclosed fi- 
nancial transaction system architecture, it is necessary 
to show how financial institution back office system is 
adapted to handle the authentication session. A finan- 
cial account holder initiates the authentication session 

20 with the financial institution back office 301 in the same 
way and through the same communication devices / 
channels as shown in FIG. 4. Although a detailed sys- 
tem and method of performing AAA at financial institu- 
tion back office will be described later, certain features 

25 specific to the authentication session features are dis- 
cussed here. 

[0049] At decision-making step 504, ACCOUNT 
NUMBER SEARCH PROGRAM module 502 is activat- 
ed in the financial institution back office CPU / dB, which 
30 transitions the authentication session to next decision- 
making step 506 ( provided financial institution EPSL ac- 
count number verification is successful. At step 506 
TRANSACTION PIN VERIFICATION PROGRAM mod- 
ule 503 is activated and transitions the authentication 

35 session to decision-making step 508, provided transac- 
tion type PIN verification in the financial institution back 
office dB is successful. At step 508 IDENTITY PIN RAN- 
DOM SUBSET GENERATOR module 505 is activated 
at financial institution back office CPU and transitions 

40 the authentication session to decision-making step 509, 
provided a random subset of digits is validated at the 
financial institution back office dB. At step 509 AC- 
COUNT CONSISTENCY PROGRAM module 507 is ac- 
tivated at the financial institution back office CPU and 

45 transitions the authentication session to decision-mak- 
ing step 511 , provided the transaction amount of money, 
specified by financial account holder during an authen- 
tication session does not exceed available funds in the 
account. At step 511 the authentication session is com- 

50 pleted at the financial institution back office and the ac- 
counting session is begun 510, unless the financial in- 
stitution EPSL card is in the list of lost, stolen or fraud- 
ulently used, which would lead to rejecting the entire au- 
thentication session. Otherwise, the authentication file 

55 will be generated, time stamped and put on hold at fi- 
nancial institution back office dB concurrently with the 
alphanumeric financial transaction specific signature, 
which is generated and sent to the financial account 
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holder. One may note that a number of program mod- 
ules 502, 503, 507 and 510 are incorporated into finan- 
cial institution back office software environment to per- 
form an authentication session. This is just a part of the 
automated "clocked" AAA sessions, which constitute 
the system and method at financial institution back office 
to enable financial institution EPSL technology. 
[0050] FIG. 6 shows an interface protocol of the EPSL 
architecture. The columns correspond to nodes that 
process parameters. A parameter name in a cell shows 
where the parameter is originated. If an arrow onset be- 
gins from the cell, where a parameter is originated, an 
arrowhead shows where the parameter is delivered to 
for further processing. If an arrow onset cell location is 
different than the cell location in the same row at which 
the parameter originates, this arrow shows a destination 
cell to which a parameter was moved for processing in 
an earlier exchange, and from which it is moved again 
as indicated by the arrow. 

[0051] Parameter ACC#_{XYZ} 601 is financial insti- 
tution EPSL account number. "XYZ" should be broadly 
constructed to mean a certain number, which uniquely 
characterizes financial institution EPSL financial ac- 
count holder. Parameter W_PIN 602 is a withdraw trans- 
action PIN secret number. Parameter D_PIN 603 is a 
deposit transaction PIN secret number. Parameter W$ 
604 is withdrawal transaction amount, specified by fi- 
nancial account holder during an authentication ses- 
sion. Parameter D$ 605 is a deposit transaction amount, 
specified by financial account holder during an authen- 
tication session. Parameter ID_PIN 606 is the identity 
PIN secret number, used by financial institution back of- 
fice and financial account holder during an interactive 
part of an authentication session. Parameter (W/D) 
#_GEN(ACC#_{XYZ}, (W/D)_PIN, ID_PIN ; (W/D)$, 
TX 1)607 is an alphanumeric signature, generated at the 
end of a successful authentication -session. (W/D) 
#_GEN is a function of other parameters, listed above. 
The only unknown yet parameter is TX1 , which is a time 
point at which an authentication session is successfully 
completed (see FIG. 9). Parameter T_INT((W/D) 
#_GEN(ACC#_{XYZ}, (W/D)_P!N, ID_PIN : (W/D)$, 
TX1)) 608 is a time interval, counted from the moment 
TX1 . It specifies an alphanumeric signature lifetime for 
a specific financial transaction derived internally at fi- 
nancial institution back office at the end of a successful 
authentication session. Parameter ACC#_{XYZ}_TX1 
609 is an authentication file name, defined at the end of 
a successful authentication session inside financial in- 
stitution back office. Parameter ACC#_{XYZ}_TX2 610 
is an authorization file name, defined at the beginning 
of a successful entry data transfer at the beginning of 
an authorization session inside financial institution back 
office. Parameter BUS# 611 is a merchant/ seller/ ven- 
dor standard ID number specified by a party at the point 
of sale during an authorization session request. Param- 
eter T-AMOUNT 612 is an exact amount of money, re- 
quired to perform financial transaction and specified by 



a party at the point of sale (or a bank teller) during an 
authorization session request. 

[0052] FIG. 7 shows a flow diagram of the EPSL au- 
thorization session. It corresponds to steps 305 - 306 - 
5 307 in FIG. 3. All together they constitute the authoriza- 
tion session of financial transaction. A party at the point 
of sale can access the financial institution back office to 
initiate the authorization session using the same devic- 
es / communication lines 401-405 as financial account 

10 holder, when initiating the authentication session (see 
FIGS. 4-5). Though a detailed system and method of 
performing AAA at financial institution back office will be 
described later, certain specific to the authorization ses- 
sion features can be described here. 

75 [0053] At decision-making step 704, ACCOUNT 
NUMBER SEARCH PROGRAM module 502 is activat- 
ed at financial institution back office CPU / dB and tran- 
sitions the authorization session to decision-making 
step 706, provided the account number is positively ver- 

20 if ied at the financial institution back office dB. Otherwise, 
the authorization session is denied. At decision-making 
step 706, TRANSACTION SIGNATURE VERIFICA- 
TION PROGRAM module 703 is activated at the finan- 
cial institution back office CPU and transitions the au- 

25 thorization session to decision-making step 708 : provid- 
ed the alphanumeric transaction signature Is validated 
at the financial institution back office dB. At decision- 
making step 708, BUSINESS ID VERIFICATION PRO- 
GRAM module 705 is activated at the financial institution 

30 back office CPU and transitions an authorization ses- 
sion to decision-making step 709, provided ;a- party at 
the point of sale ID is on a list of valid, legal merchants. 
At decision-making step 709, ACCOUNT VERIFICA- 
TION PROGRAM module 707 is activated at the finan- 

35 cial institution back office CPU and transitions the au- 
thorization session to decision-making step 306 : provid- 
ed the predicted transaction amount entered by financial 
account holder at the respective authentication session 
is more than or equal to the actual amount, entered by 

40 a party at the point of sale, while requesting the author- 
ization session. At decision-making step 306, the finan 1 
cial institution back office completes authorization and 
accounting sessions, provided the credit / debit EPSL 
account card is not on a list of lost, stolen or fraudulently 

45 used cards. This checks again whether there are no sus- 
picious issues related to this particular account since the 
authentication session was completed. 
[0054] It can be noted here that a number of program 
modules 502, 703, 705, 707 and 307 are incorporated 

50 jnto financial institution back office software environ- 
ment to perform an authorization session. As will be 
seen later, this is part of the automated "clocked" AAA 
sessions, which constitute the system and method im- 
plemented at the financial institution back office to ena- 

55 ble financial institution EPSL technology. 

[0055] FIG. 8 shows the EPSL transaction checklist. 
Pluses mean that a particular parameter in a respective 
row is used during one of AAA sessions, specified at the 
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top of the columns. Minuses mean that parameters are 
not used. 

[0056] FIGS. 9A, 9B and 9C illustrate a synthesis of 
a timing diagram, a flow chart and a functional diagram 
of the EPSL architecture based on the "clocked" AAA 
technology. One may note that the part, related to the 
AUTHENTICATION SESSION (a dotted line of a non- 
numbered cell), is already presented in FIGS. 4-5, while 
the part named the AUTHORIZATION SESSION (also 
a dotted line of a non-numbered cell) is described in FIG. 
7. 

[0057] The financial institution back office has GLO- 
BAL CLOCK PROGRAM module 902. A hardware 
equivalent is implemented as a silicon digital integrated 
circuit internal clock (with a typical rate approximately 
within the range (10 - 1,000) MHz). Module 902, which 
can be fed by similar clock at financial institution back 
office CPU, synchronizes all program modules during 
AAA sessions. Each financial transaction beginning 
from the start of the authentication session and up to the 
end of the authorization and accounting sessions is 
processed depending on their time position, defined by 
the global clock. The global clock synchronizes all pro- 
gram modules. Every program module is activated by 
one of the other program modules once its job is com- 
pleted. Key information elements of financial transac- 
tions stored in financial institution back office dB (for in- 
stance, authentication and authorization files) are strict- 
ly analyzed and differentiated depending on their posi- 
tions in time, which is a part of a decision making proc- 
ess at financial institution back office. The global clock 
program module enables financial transaction related 
timing components and parameters identification as 
well as the entire EPSL system of program modules and 
hardware synchronization at financial institution back of- 
fice. 

[0058] A financial account holder initiates the authen- 
tication session with the financial institution back office 
through any of described above devices / communica- 
tion lines by entering a series of numbers (three tiers 
security protection system described above). Once the 
beginning of a communication session is established, 
module ACCOUNT NUMBER SEARCH PROGRAM 
502 is activated, requesting the financial account holder 
to enter a financial institution EPSL account number. 
Once the financial account holder has entered ACC#_ 
{XYZ} 601 , if ACC#_{XYZ} is positively verified, module 
502 activates module TRANSACTION PIN VERIFICA- 
TION PROGRAM 503 and stops its own execution. If 
ACC#_{XYZ} is not verified at the financial institution 
back office dB, the financial transaction authentication 
session is denied and module 502 stops execution with- 
out activating module 503. Decision-making routine 
ACC# 504 is a part of module 502 and makes a decision 
whether to activate module 503 or not, based on ACC#_ 
{XYZ} verification results at financial institution back of- 
fice dB. 

[0059] TRANSACTION PIN VERIFICATION PRO- 



GRAM module 503, once activated, requests the finan- 
cial account holder to enter a transaction PIN and exe- 
cutes, once Ihe W_PIN 602 or D_PIN 603 is entered. 
Decision-making routine T_PIN 506, which is a part of 

5 module 503, stops module 503 and activates IDENTITY 
PIN RANDOM SUBSET GENERATOR module 505, 
provided (W/D)_PIN is positively verified at the financial 
institution back office dB. Otherwise, routine T_PIN 506 
stops module 505 and the financial transaction authen- 

10 tication session is denied. 

[0060] Module 505 once activated, generates a re- 
quest to the financial account holder to submit in se- 
quence a certain random combination of digits that con- 
stitute a subset of a financial account holder identity PIN 

15 secret number ID_PIN 606 and then executes on ana- 
lyzing a received reply, entered by financial account 
holder during this interactive session (the third tier of fi- 
nancial institution back office security protection). Deci- 
sion-making routine ID_PIN 508, which is a part of mod- 

20 U le 505, stops module 505 and activates financial insti- 
tution back office ACCOUNT CONSISTENCY PRO- 
GRAM module 507, provided the random subset of dig- 
its, entered by financial account holder per the request 
of module 505 is positively validated at financial institu- 

25 tion back office dB. Otherwise, routine ID_PIN 508 stops 
module 505 execution without activating module 507 
and the financial transaction authentication session is 
denied. 

[0061] A financial institution back office ACCOUNT 

30 CONSISTENCY PROGRAM module 507, once activat- 
ed, requests the financial account holder to enter a pre- 
dicted withdraw transaction amount W$ 604 or predict- 
ed deposit transaction amount D$ 605 and executes, 
once (W7D)$ is entered. Decision-making routine 509, 

35 which is a part of module 507, stops module 507 and 
activates TRANSACTION SIGNATURE GENERATOR 
module 905, provided W$ does not exceed the amount 
of money available on this financial institution EPSL ac- 
count. Otherwise, routine (W/D)$ 509 stops module 507 

40 execution without activating module 905 and the finan- 
cial transaction authentication session is denied. 
[0062] TRANSACTION SIGNATURE GENERATOR 
module 905, once activated, generates an alphanumer- 
ic signature, provided all previous steps 504, 506, 508 

45 and 509 are successful. Decision-making routine (W/D) 
#_GEN 51 1 , which is a part of module 905, stops module 
905 and activates module 904, provided the credit / debit 
financial institution EPSL account card is not on a list of 
lost, stolen orfraudulently used cards. Concurrently with 

50 activating module 904, routine 511 sends the alphanu- 
meric transaction signature to the financial account 
holder 510. 

[0063] AUTHENTICATION FILE GENERATOR 
module 904, once activated, creates an electronic 
55 record, which contains some or all of the information 
gathered together during the authentication session: 
ACC#JXYZ} 601 , (W/D)_PIN 602 or 603, ID_PIN 606, 
(W/D)$ 604 or 605 and (W/D)#_GEN 607. The record 
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is given a file name is ACC#_{XYZ}_TX1 609, which is 
a combination of financial institution EPSL account 
number and a time mark TX1 . TX1 is a time moment, at 
which file ACC#_{X YZ}_TX 1 907 is generated in finan- 
cial institution back office dB. Practically speaking, it is 
the same time as when the financial account holder ob- 
tains his alphanumeric signature for a requested finan- 
cial transaction. The time mark TX1 is assigned at the 
end of the authentication session for the financial ac- 
count holder and financial institution back office in this 
example. The authentication record with the file name 
ACC#_{XYZ}_TX1 can be created irrespective to which 
operating system is deployed at financial institution back 
office dB (for instance, UNIX / Solaris or Windows NT). 
Module 904 activates module 901 at the time moment 
TX1. 

[0064] Financial institution back office WATCHDOG 
PROGRAM module 901 , starting from the time moment 
TX1, searches financial institution back office dB after 
each small time interval (which can range for example, 
from several milliseconds to several seconds, depend- 
ing on actual hardware / software implementation of fi- 
nancial institution back office CPU and dB). The search 
checks whether there is another record with the same 
root name ACC#_{XYZ} and suffix TX2 greater than TX1 
(TX2 > TX1). Module 901 can work in this mode of op- 
eration during time interval TJNT 608, which starts at 
TX1 and is set at financial institution back office to a rea- 
sonable time to perform a predicted financial transaction 
after the authentication session (for instance, a half an 
hour). Otherwise, it can be chosen by the financial ac- 
count holder during the authentication session within 
certain range (for example, from a quarter of an hour to 
several hours). The record with file name ACC#_{XYZ} 
_TX2 906, which financial institution back office 
WATCHDOG PROGRAM module 901 is searching for, 
is created during the authorization session, requested 
by a party at the point of sale from the financial institution 
back office. The authentication session completed at the 
moment TX1 is followed by the authorization session, 
which has an intermediate stage of creating an author- 
ization record at financial institution back office at some 
later time moment TX2 after TX1. The authorization file 
structure and its role in the "clocked" AAA technology 
will be discussed later along with the authorization ses- 
sion description. 

[0065] The financial institution back office WATCH- 
DOG PROGRAM module 901 stops searching for an au- 
thorization file 906 at the moment TX1 -+- T_INT. Any au- 
thorization session, initiated by a party at the point of 
sale after that time will be denied with a message that 
the transaction signature is timed out. The financial ac- 
count holder will need to initiate another authentication 
session for the same financial transaction to make it 
happen. Strictly speaking, module 901 will keep search- 
ing financial institution back office dB after the moment 
TX1 + T_INT with gradually increased time interval be- 
tween consecutive search sessions (for instance, dou- 



ble interval for TX1 + T_INT < t < TX1 + 2* T_INT, triple 
interval for TX1 + 2 # TJNT < t < TX1 +- 3 * TJNT, etc.). 
However, its function is changed. When the authoriza- 
tion file is found, module 901 will forbid financial trans- 

5 action with the error message that financial transaction 
is timed out. At certain time moment (for instance, TX1 
-♦- 10 * T_INT) module 901 completely stops searching 
for the authorization file ACC#_{XYZ}_TX2 906. Any au- 
thorization session initiated by a party at the point of sale 

10 for the same financial transaction will be simply denied 
from now on. 

[0066] The reason module 901 search repetition time 
interval is getting gradually increased after the moment 
TX1 + T_INT is to reduce the load on financial institution 

15 back office CPU. Limiting the lifetime of transaction sig- 
natures and making them specific to particular financial 
transactions allow eliminating any fraudulent actions 
based on decryption of these signatures. It greatly en- 
hances security in using non-secure communication 

20 lines and line input / output devices. It is especially im- 
portant for on line financial transaction and makes the 
EPSL technology a very suitable architecture for elec- 
tronic commerce as well as for offline financial transac- 
tions. 

25 [0067] The financial account holder applies to a party 
at the point of sale (or a bank teller) after obtaining the 
alphanumeric transaction signature at the end of the au- 
thentication session. A party at the point of sale* (mer- 
chant or a bank teller) initiates an authorization session 

30 with the financial institution back office using the-saime 
devices /communication lines as possible during the au- 
thentication session (see financial institution GS. 4-5). 
A party at the point of sale gets from the financial'ac- 
count holder, a financial institution EPSL account 

35 number and a financial transaction alphanumeric signa- 
ture. Then the party at the point of sale adds up a stand- 
ard business identification (merchant) number BUS# 
611 and an actual transaction amount of money 
T-AMOUNT 612 necessary to perform financial trans- 

40 action. Those are added to the authorization process for 
accounting processing at financial institution back office 
during the accounting session. 

[0068]^ At decision-making step 704, ACCOUNT 
NUMBER SEARCH PROGRAM module 502 is activat- 
es ed, once a party at the point of sale sends the ACC#_ 
{XYZ} 601 and it is received at financial institution back 
office. Then module 502 performs two steps, provided 
ACC#_{XYZ} 601 is a legitimate one (positively verified 
at the financial institution back office dB). Module 502 
50 activates AUTHORIZATION FILE GENERATOR mod- 
ule 903 at the time moment TX2, which actually symbol- 
izes the beginning of the authorization session at finan- 
cial institution back office. Module 903 creates the au- 
thorization record with file name ACC#_{XYZ}_TX2 906 
55 in the financial institution back office dB, and is kept ac- 
tive during the time when all authorization session entry 
information is passing through steps 706 - 708 - 709 and 
eventually gathered together in the authorization record 
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ACC#_{XYZ}_TX2. In the second step, module 502 
transitions the authorization session to decision-making 
step 706, provided again the account number 601 is 
positively verified at financial institution back office dB. 
Otherwise, the authorization session is denied through 
dedicated device 701 at financial institution back office, 
notifying a party at the point of sale with the error mes- 
sage of incorrect financial institution EPSL account 
number. 

[0069] WATCH DOG PROGRAM module 901 activat- 
ed at the moment TX1 keeps periodically searching fi- 
nancial institution back office dB. It is looking for the au- 
thorization record, which complements to the authenti- 
cation record ACC#_{XYZ}_TX1 and, once the author- 
ization record ACC#_{XYZ}_TX2 is created, module 
901 eventually finds it. If the authorization record is cre- 
ated during time interval TX1 < t < TX1 + TJNT, the 
authorization session is continuing. Otherwise, it is de- 
nied. WATCHDOG PROGRAM module 901 right after 
the authorization file is found and positively identified 
with respect to time it is created, activates TRANSAC- 
TION SIGNATURE VERIFICATION PROGRAM module 
703, ACCOUNTING SESSION VERIFICATION PRO- 
GRAM module 707 and BUSINESS ID VERIFICATION 
PROGRAM module 705. All these modules start 
processing information they are looking for in the au- 
thorization record or keep periodically looking at this 
record, until the expected information appears there af- 
ter steps 706 - 708 - 709. 

[0070] At decision-making step (W/D)#_GEN 706 the 
financial transaction alphanumeric signature is already 
transferred from a party at the point of sale to the finan- 
cial institution back office and module 703 is activated 
(if it is not activated yet by module 901) and compares 
alphanumeric signatures in the authentication record 
and the authorization record. In a case they match, mod- 
ule 703 transitions the authorization session to decision- 
making step BUS# 708. Otherwise, the authorization 
session is denied with the error message that the trans- 
action signature is incorrect. 

[0071] At decision-making step BUS# 708, a party at 
the point of sale business ID BUS# 61 1 is already trans- 
ferred from a party at the point of sale to the financial 
institution back office and BUSINESS ID VERIFICA- 
TION PROGRAM module 705 is activated unless it was 
already activated by module 901. Module 705 checks 
whether a party at the point of sale BUS# is on the list 
of valid, legal merchants and then transitions the author- 
ization session to decision-making step T-AM 709. Oth- 
erwise, the authorization session is denied with the error 
message that merchant ID is incorrect. 
[0072] At decision-making step T-AM 709, a party at 
the point of sale specified exact transaction amount of 
money T-AMOUNT 612 transferred from a party at the 
point of sale to financial institution back office, is written 
to the authorization record 906 and ACCOUNTING 
SESSION VERIFICATION PROGRAM module 707 is 
activated, unless it was already activated by module 



901 . Module 707 reads out T-AMOUNT from the author- 
ization record 906 and checks whether it is less or equal 
to the withdraw or deposit amount (W/D)$ specified in 
the authentication record 907. If T-AMOUNT is less or 

5 equal (=<) (W/D)$ (T-AMOUNT =< (W/D)$), module 707 
locks T-AMOUNT at the financial account holder finan- 
cial institution EPSL account to assure the payment to 
a party at the point of sale (after deductions of the trans- 
action fee to the card issuing bank and the discount rate 

10 to the acquiring bank or an independent sales organi- 
zation). This completes the accounting session, which 
is performed next after the authorization session. 
[0073] If module 502 and 703 positively identifies a 
financial transaction after comparing authorization 

15 record 906 and authentication record 907 at decision- 
making step T-SIGN VERIF 908, the authorization ses- 
sion is transitioned to decision-making step 306. Other- 
wise, the authorization session is denied through dedi- 
cated device / channel 701 at financial institution back 

20 office. 

[0074] At decision making step ACC-VERIF 306, the 
accounting session gets completed and the financial 
transaction is permitted, provided module 705 and 707 
positively identified BUS# 611 and T-AMOUNT 612 at 
25 financial institution back office dB. Otherwise, the finan- 
cial transaction is denied. As can be seen, a successful 
completion of the accounting session is an essential part 
of the entire authorization process. The authorization 
code is sent to the financial account holder through ded- 

30 icated device / channel 909 from the financial institution 
back office, provided the accounting session is success- 
fully completed and the credit / debit financial institution 
EPSL account card is not on a list of lost, stolen or fraud- 
ulently used cards. This allows checking again whether 

35 there are no suspicious issues related to this particular 
account since the authentication session was complet- 
ed. Authentication and authorization records are kept in 
financial institution back office dB for ongoing account- 
ing control until they are archived. 

40 [0075] Several notes about the described above 
"clocked" AAA technology at financial institution back of- 
fice follow. First, how to perform chargeback using this 
technology is described. Chargeback is a credit card 
transaction that is billed back to a party at the point of 

45 sale, who made the sale. This occurs when financial ac- 
count holder disputes a charge on their bill by claiming 
the product was never delivered or financial account 
holder was dissatisfied with it in some way. If a party at 
the point of sale and financial account holder agrees 

so with the chargeback and its amount, the financial ac- 
count holder requests financial institution back office to 
authenticate a deposit financial transaction using D_PIN 
secret number during the authentication session (in- 
stead of usually used W_PlN for buy / sell transactions). 

55 Then financial account holder submits to a party at the 
point of sale the alphanumeric signature along with the 
EPSL account number. In other words, chargeback is 
performed as a regular financial transaction with the on- 
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ly difference that the transaction signature generated at 
financial institution back office is for deposit financial 
transaction. Then a party at the point of sale requests 
financial institution back office to authorize this financial 
transaction in the same way as a withdraw financial 
transaction . Once the transaction is authorized at finan- 
cial institution back office, a request to lock the charge- 
back amount is sent to the acquiring bank or an inde- 
pendent sales organization, where this merchant ac- 
count is residing in order to guarantee the payment back 
to financial account holder. EPSL chargeback mecha- 
nism allows performing this financial transaction within 
standard EPSL architecture (referring back to FIG. 3) 
without disclosing to a party at the point of sale financial 
account holder private personal information. 
[0076] The financial institution back office "clocked" 
AAA technology is adapted to service a party at the point 
of sale during authorization sessions requested by them 
independent of the entry data flow rate on particular de- 
vices and / or communication lines. In an extreme case, 
when a party at the point of sale enters ACC#_{XYZ), 
(W/D)#_GEN, BUS# and T-AMOUNT manually, mod- 
ules 703, 705 and 707 are activated by module 901, 
once module 502 verifies ACC#_{XYZ} and the author- 
ization record ACC#JXYZ}_TX2 906 is created in the 
financial institution back office dB. This file can be empty 
for a while, until the following parameters are entered. 
Until then each of the mentioned modules 703, 705 and 
707 periodically looks at the authorization file, and picks 
up the parameter of interest as soon as it arrives at fi- 
nancial institution back office and is written into the au- 
thorization file. Alternatively, in the case that a party at 
the point of sale uses a specialized point-of-sale POS 
devices, which allow for high speed electronic data entry 
for the listed above parameters, modules 703, 705 and 
707 will find needed parameters in the authorization file 
ACC#_{XYZ}_TX2 at the very first moment they were 
activated. In this case, modules 703, 705 and 707 could 
be activated by decision-making routines 706, 708 and 
709 sooner than by module 901 . That depends on spe- 
cifics of hardware and software implementation of the 
"clocked" AAA technology at financial institution back of- 
fice. Summarizing, it can be said that financial transac- 
tion authorization session processing time is not limited 
by financial institution back office "clocked" AAA tech- 
nology, but rather by the entry data flow rate at a party 
at the point of sale locations. 

[0077] Authentication sessions in EPSL "clocked" 
AAA technology are not time limited and can not be re- 
placed by an automated electronic interaction between 
financial account holder devices (for instance, smart 
cards or mobile phones) and financial institution back 
office. It is because they include an interactive commu- 
nication sessions between financial account holders 
and the financial institution back office, which consti- 
tutes the third security protection tier. This is sort of a 
trade off between financial institution EPSL technology 
security protection and inconvenience in using this tech- 



nique. Fortunately, authentication sessions in the EPSL 
technology are performed prior to financial transaction, 
and the financial account holder can choose a time, 
when he / she is comfortable to get the transaction sig- 

5 nature from financial institution back office. The way the 
financial account holder keeps the transaction signature 
after the authentication session is completed and before 
it is submitted to a party at the point of sale can vary. It 
can range from just writing it down into a notebook, to 

10 storing it electronically inside devices like smart cards, 
digital personal organizers with wireless connection ca- 
pabilities and other electronic devices with read / write 
memory capabilities. 

[0078] Smart card technology is an excellent comple- 
*5 ment to make EPSL technology more comfortable for 
the financial account holder and the third party at the 
point of sale. Smart cards can be used as intermediate 
information carriers between the financial institution 
back office, which will write financial transaction signa- 
ge tures into smart cards during authentication sessions, 
and the financial account holder. Then it can be read out 
from smart cards at the point of sale locations to speed 
up authorization session requests. This way there are 
no issues with smart card security protection, since they 
25 can not be reused. Even if a smart card is lost or stolen 
before the current financial transaction signature was 
deactivated during an expected financial transaction at 
the point of sale location, nobody knows, what was (W7 
D)$ amount requested and how close this transaction 
50 signature is to its lifetime end. Moreover, even the fact 
that the card may still carry a signature is not apparent. 
Therefore, chances are high that even in this case fraud- 
ulent actions will be unsuccessful. More than that, a 
smart card may not contain financial institution EPSL ac- 
35 count number (it could be residing on EPSL member- 
ship cards). In this case, smart cards have absolute se- 
curity protection against fraudulent actions at any time. 
[0079] Mobil phones, network computers or other 
portable electronic devices having information read / 
^0 write capabilities can be made as convenient as smart 
cards, functioning as intermediate authentication infor- 
mation carriers for one specific financial transaction (fi- 
nancial transaction alphanumeric signatures) between 
financial institution back office and a party at the point 
^5 of sale. 

[0080] The last note relates to utilizing financial insti- 
tution EPSL architecture with "clocked" AAA technology 
at ATM stations. A financial account holder can perform 
an authentication session for a withdraw financial trans- 

50 action either before or right during operations at ATM 
stations. In any event, once the authentication session 
with financial institution back office is completed, the fi- 
nancial account holder operates at ATM station as at the 
point of sale location, provided ATM stations hardware 

55 and software are altered to perform authorization re- 
quests in the EPSL architecture. This makes money 
withdraw sessions at ATM stations highly secured and 
protected against information to be looked after, stolen 
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or fraudulently used, while preserving complete privacy 
of personal information. 

[0081] Finally, it should be emphasized that the de- 
scribed innovation can be used on and off line, and for 
private and non-private sessions, in all cases for a highly 
secure financial transaction . If a financial account holder 
is not concerned with financial transaction privacy, the 
financial account holder name can be placed on the card 
and become one more parameter utilized in the 
"clocked" AAA technology. Meanwhile, use of EPSL fi- 
nancial transaction architecture and the "clocked" AAA 
technology for non-private financial transactions pro- 
vides improved (essentially, "bullet prove") security of 
on and off line financial transaction. The entire EPSL 
architecture and the "clocked" AAA at financial institu- 
tion back office for non-privatefinancial transactions can 
be viewed as the fourth security tier whereas in a case 
of private financial transactions, it is still the fourth se- 
curity layer and the main embedded privacy layer as 
well. 

[0082] Though the invention has been described in 
connection with preferred embodiments of the system 
and method for private and secure transactions, it is un- 
derstood that the preferred embodiments have been 
used for the purpose of illustrating the manner in which 
the invention may be made and used. It should also be 
understood that implementation of other variations and 
modifications of the invention and its various aspects will 
be apparent to those skilled in the art, and that invention 
is not limited to these preferred embodiments described 
above. It is therefore contemplated to cover by present 
invention any and all modifications, variations, or equiv- 
alents that fall within the scope of claims. 



Claims 

1 . A method for managing financial transactions, com- 
prising: 

performing an authentication process for a pre- 
dicted transaction by a particular account hold- 
er, the predicted transaction having a predicted 
transaction amount and a predicted transaction 
time, the authentication process producing a 
transaction signature for presentation upon ex- 
ecution of the predicted transaction; 
performing an authorization process for a par- 
ticular transaction having actual transaction 
amount and an actual transaction time upon 
presentation of the transaction signature : in- 
cluding verifying that the presented transaction 
signature matches the transaction signature for 
the predicted transaction, the actual transac- 
tion amount matches the predicted transaction 
amount and the actual transaction time match- 
es the predicted transaction time; and 
performing an accounting process for the par- 



10 



15 



20 



ticular transaction as a result of a successful 
authorization process, including reconciling the 
predicted transaction amount and the actual 
transaction amount for the particular account 
holder. 

2. The method of claim 1 , including: 

storing the predicted transaction amount and 
the transaction signature for a predicted trans- 
action in a database. 

3. The method of claim 2, including storing a predicted 
transaction time in the database. 

4. The method of claim 1 , including setting up a time 
out interval between the authentication process and 
the authorization process. 



The method of claim 1 
process includes: 



30 



35 



40 



6. 



50 



55 



, wherein the authentication 



establishing a communication session between 
the particular account holder and a financial 
transaction server; 

atthe server, accepting an account number and 
an identification number for the particular ac- 
count holder; 

at the server, accepting the predicted transac- 
tion amount; 

at the server, producing the transaction signa- 
ture and sending the transaction signature to 
the particular account holder; and 
entering identifying information for the predict- 
ed transaction in a memory at the server. 

The method of claim 5, wherein the authentication 
process includes prompting the particular account 
holder to supply a combination of digits from a per- 
sonal identification code, wherein the combination 
does not include all of the personal identification 
code. 



The method of claim 1 
process includes: 



, wherein the authorization 



establishing a communication session between 
a party to the particular transaction and a finan- 
cial transaction server; 

atthe server, accepting the presented transac- 
tion signature and the actual transaction 
amount; 

at the server, comparing a time of the particular 
transaction with the predicted time : and com- 
paring the presented transaction signature and 
actual transaction amount with the predicted 
transaction amount associated with the trans- 
action signature for the predicted transaction; 
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and 

at the server, sending an authorization mes- 
sage to the party. 

The method of claim 7, including accepting identifi- 5 
cation of the party at the server. 

The method of claim 7, wherein the authorization 
process operates without identification of the par- 
ticular account holder to the party. 10 



signature stored for the predicted transaction, 
the actual transaction amount matches the pre- 
dicted transaction amount and the authoriza- 
tion time meets a time criterion; and 
executing an accounting process for the partic- 
ular transaction as a result of a successful au- 
thorization process, including reconciling the 
predicted transaction amount and the actual 
transaction amount for the particular account 
holder. 



10. The method of claim 7, wherein the authorization 
process operates with identification of the particular 
account holder to the party. 

11. The method of claim 1, wherein the authentication 
process includes routines: 



13. The method of claim 12, including: 

storing the transaction signature and the pa- 
rameters associated with the predicted trans- 
action in a database. 

14. The method of claim 13, including storing a param- 
eter indicating acceptable transaction times in the 
database. 

1 5. The method of claim 1 2, including setting up a time 
out interval between the authentication time and the 
authorization time. 

16. The method of claim 12, wherein the authentication 
process includes: 

establishing a private communication session 
between the particular account holder and a fi- 
nancial transaction server; 
at the server, accepting an account number and 
an identification number for the particular ac- 
count holder; 

at the server, accepting the predicted transac- 
tion amount; 

at the server, producing the transaction signa- 
ture and sending the transaction signature to 
the particular account holder; and 
entering identifying information for the predict- 
ed transaction in a memory at the server. 

17. The method of claim 16, wherein the authentication 
process includes prompting the particular account 
holder to supply a combination of digits from a per- 
sonal identification code, wherein the combination 
does not include all of the personal identification 
code. 

18. The method of claim 12, wherein the authorization 
process includes: 

establishing a private communication session 
between a party to the particular transaction 
and a financial transaction server; 
at the server, accepting the presented transac- 
tion signature and the actual transaction 
amount; 



establishing a communication session between 
the particular account holder and a financial 20 
transaction server; 

accepting an account number as input; 
prompting the particular account holder to sup- 
ply a static identification number and a dynam- 
ically identified combination of digits from a per- 25 
sonal identification code, wherein the combina- 
tion does not include all of the personal identi- 
fication code; 

accepting the predicted transaction amount as 
input; 30 
producing the transaction signature and send- 
ing the transaction signature to the particular 
account holder; and 

entering identifying information for the predict- 
ed transaction in a memory. 35 

1 2. A method for managing financial transactions, com- 
prising: 

executing an authentication process over com- 40 
munication media for a predicted transaction by 
a particular account holder, including receiving 
a predicted transaction amount at an authenti- 
cation time, the authentication process produc- 
ing a transaction signature for presentation up- 45 
on execution of the predicted transaction, com- 
municating the transaction signature to the par- 
ticular account holder, and storing the transac- 
tion signature and parameters associated with 
the particular transaction; so 
executing an authorization process over com- 
munication media for a particular transaction 
having actual transaction amount and an actual 
transaction time, including receiving the trans- 
action signature over communication media 55 
from a party to the particular transaction at an 
authorization time, verifying that the received 
transaction signature matches the transaction 
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at the server, determining whether the authori- 
zation time falls within an acceptable time win- 
dow, and comparing the presented transaction 
signature and actual transaction amount with 
the predicted transaction amount associated 
with the transaction signature for the predicted 
transaction; and 

at the server, sending an authorization mes- 
sage to the party. 

19. The method of claim 1 B, including accepting identi- 
fication of the party at the server. 

20. The method of claim 18, wherein the authorization 
process operates without identification of the par- 
ticular account holder to the party. 

21. The method of claim 18, wherein the authorization 
process operates with identification of the particular 
account holder to the party. 

22. The method of claim 1 2, wherein the authentication 
process includes: 

establishing a communication session between 
the particular account holder and a financial 
transaction server; 

accepting an account number as input; 
prompting the particular account holder to sup- 
ply a static identification number and a dynam- 
ically identified combination of digits from a per- 
sonal identification code, wherein the combina- 
tion does not include all of the personal identi- 
fication code; 

accepting the predicted transaction amount as 
input; 

producing the transaction signature and send- 
ing the transaction signature to the particular 
account holder; and 

entering identifying information for the predict- 
ed transaction in a memory. 

23. A financial transaction server, comprising: 

a communication interface; 
a data processing system coupled to the com- 
munication interface, the data processing sys- 
tem including resources for managing financial 
transactions, including 

an authentication process communicating over 
the communication interface for authenticating 
predicted transaction by a particular account 
holder, including routines which handle receiv- 
ing a predicted transaction amount at an au- 
thentication time, producing a transaction sig- 
nature for presentation upon execution of the 
predicted transaction, communicating the 
transaction signature to the particular account 



holder, and storing the transaction signature 
and parameters associated with the particular 
transaction: 

an authorization process communicating over 
5 the communication interface for authorizing a 

particular transaction having actual transaction 
amount and an actual transaction time, includ- 
ing routines for handling receiving the transac- 
tion signature over the communication inter- 
10 face from a party to the particular transaction 

at an authorization time, verifying that the re- 
ceived transaction signature matches the 
transaction signature stored for the predicted 
transaction, that the actual transaction amount 
is matches the predicted transaction amount and 

that the authorization time meets a time criteri- 
on; and 

an accounting process executed for the partic- 
ular transaction as a result of a successful au- 
20 thorizatton process, including routines reconcil- 

ing the predicted transaction amount and the 
actual transaction amount forthe particular ac- 
count holder. 

25 24. The financial transaction server of claim 23, where- 
in the data processing system includes a local or 
remote database storing the transaction signature 
and the parameters associated with the predicted 
transaction. 

30 

25. The financial transaction server of claim 24, includ- 
ing a parameter indicating acceptable transaction 
times stored in the database. 

35 26. The financial transaction server of claim 23, where- 
in the data processing system includes a routine 
setting up a time out interval between the authenti- 
cation time and the authorization time. 

40 27. The financial transaction server of claim 23, where- 
in the authentication process includes routines: 

establishing a private communication session 
between the particular account holder and a fi- 
45 nancial transaction server; 

accepting an account number and an identifi- 
cation number forthe particular account holder; 
accepting the predicted transaction amount; 
producing the transaction signature and send- 
so ing the transaction signature to the particular 

account holder; and 

entering identifying information for the predict- 
ed transaction in a memory. 

55 28. The financial transaction server of claim 27, where- 
in the authentication process includes a routine 
prompting the particular account holder to supply a 
combination of digits from a personal identification 
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code, wherein the combination does not include all 
of the personal identification code. 

29. The financial transaction server of claim 23, where* 
in the authorization process includes routines: 5 

establishing a private communication session 
between a party to the particular transaction 
and a financial transaction server; 
accepting the presented transaction signature 10 
and the actual transaction amount; 
determining whetherthe authorization time falls 
within an acceptable time window, and compar- 
ing the presented transaction signature and ac- 
tual transaction amount with the predicted '5 
transaction amount associated with the trans- 
action signature for the predicted transaction; 
and 

sending an authorization message to the party. 

20 

30. The financial transaction server of claim 29, where- 
in the authorization process includes a routine ac- 
cepting identification of the party at the server. 

31. The financial transaction server of claim 29, where- 25 
in the authorization process operates without iden- 
tification of the particular account holder to the par- 
ty. 

32. The financial transaction server of claim 29, where- 30 
in the authorization process operates with identifi- 
cation of the particular account holder to the party. 

33. The financial transaction server of claim 23, where- 
in the authentication process includes routines: 35 

establishing a communication session between 
the particular account holder and a financial 
transaction server; 

accepting an account number as input; 40 
prompting the particular account holder to sup- 
ply a static identification number and a dynam- 
ically identified combination of digits from a per- 
sonal identification code, wherein the combina- 
tion does not include all of the personal identi- 4 $ 37. 
fication code; 

accepting the predicted transaction amount as 
input; 

producing the transaction signature and send- 
ing the transaction signature to the particular so 
account holder; and 

entering identifying information for the predict- 
ed transaction in a memory. 

34. A article of manufacture, comprising: 55 

a machine readable storage medium; 
a computer program stored on said machine 



readable medium with resources for managing 
financial transactions, including 
an authentication process communicating over 
the communication interface for authenticating 
predicted transaction by a particular account 
holder, including routines which handle receiv- 
ing a predicted transaction amount at an au- 
thentication time, producing a transaction sig- 
nature for presentation upon execution of the 
predicted transaction, communicating the 
transaction signature to the particular account 
holder, and storing the transaction signature 
and parameters associated with the particular 
transaction; 

an authorization process communicating over 
the communication interface for authorizing a 
particular transaction having actual transaction 
amount and an actual transaction time, includ- 
ing routines for handling receiving the transac- 
tion signature over the communication inter- 
face from a party to the particular transaction 
at an authorization time, verifying that the" re- 
ceived transaction signature matches the 
transaction signature stored for the predicted 
transaction, that the actual transaction amount 
matches the predicted transaction amount and 
that the authorization time meets a time criteri- 
on; and 

an accounting process executed for the partic- 
ular transaction as a result of a successful au- 
thorization process, including routines reconcil- 
ing the predicted transaction amount and the 
actual transaction amount for the particular ac- 
count holder. 

The article of claim 34, wherein the resources in- 
clude a routine for storing the transaction signature 
and the parameters associated with the predicted 
transaction in a local or remote database. 

The article of claim 35, including the parameters in- 
cluded parameter indicating acceptable transaction 
times stored in the database. * 

The article of claim 34, wherein the resources in- 
clude a routine setting up a time out interval be- 
tween the authentication time and the authorization 
time. 



38. The article of claim 34, wherein the authentication 
process includes routines: 

establishing a communication session between 
the particular account holder and a financial 
transaction server; 

accepting an account number and an identifi- 
cation numberforthe particular account holder; 
accepting the predicted transaction amount; 
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producing the transaction signature and send- 
ing the transaction signature to the particular 
account holder; and 

entering identifying information for the predict- 
ed transaction in a memory. 5 

39. The article of claim 38, wherein the authentication 
process includes a routine prompting the particular 
account holder to supply a combination of digits 
from a personal identification code, wherein the 10 
combination does not include all of the personal 
identification code. 

40. The article of claim 34, wherein the authorization 
process includes routines: *5 

establishing a private communication session 
between a party to the particular transaction 
and a financial transaction server; 
accepting the presented transaction signature 20 
and the actual transaction amount; 
determining whetherthe authorization time falls 
with in an acceptable time window, and compar- 
ing the presented transaction signature and ac- 
tual transaction amount with the predicted 
transaction amount associated with the trans- 
action signature for the predicted transaction; 
and 

sending an authorization message to the party. 

41. The article of claim 40, wherein the authorization 
process includes a routine accepting identification 
of the party at the server. 

42. The article of claim 40, wherein the authorization 
process operates without identification of the par- 
ticular account holder to the party. 

43. The article of claim 40, wherein the authorization 
process operates with identification of the particular 
account holder to the party. 

44. The article of claim 34, wherein the authentication 
process includes routines: 

45 

establishing a communication session between 
the particular account holder and a financial 
transaction server; 
accepting an account number; 
prompting the particular account holder to sup- 50 
ply a static identification number and a dynam- 
ically identified combination of digits from a per- 
sonal identification code, wherein the combina- 
tion does not include all of the personal identi- 
fication code; 55 
accepting the predicted transaction amount; 
producing the transaction signature and send- 
ing the transaction signature to the particular 
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account holder; and 

entering identifying information for the predict- 
ed transaction in a memory. 

45. A method for automated authentication, authoriza- 
tion and accounting for financial transactions, com- 
prising: 

establishing an authentication record for a pre- 
dicted transaction by a particular account hold- 
er, the predicted transaction having a predicted 
transaction amount and a transaction time pa- 
rameter, and an authenticated transaction sig- 
nature for presentation upon execution of the 
predicted transaction; 

establishing an authorization record for a par- 
ticular transaction indicating an actual transac- 
tion amount, an actual transaction time and a 
presented transaction signature; 
matching the authorization record with the au- 
thentication record to determine whether the 
presented transaction signature matches the 
authenticated transaction signature for the pre- 
dicted transaction, the actual transaction 
amount matches the predicted transaction 
amount and the actual transaction time match- 
es the transaction time parameter; and 
reconciling the predicted transaction amount 
and the actual transaction amount for the par- 
ticular account holder. 

46. The method of claim 45, including: 

storing the authentication record in a database 
including a plurality of authentication records 
for other predicted transactions. 

47. The method of claim 45, wherein the time parame- 
ter comprises a time value indicated when the au- 
thorization record was created. 

48. The method of claim 45, wherein said matching in- 
cludes determining whether the actual transaction 
time falls within a time interval indicated by the 
transaction time parameter. 

49. The method of claim 45, wherein establishing an 
authentication record includes: 

establishing a communication session between 
the particular account holder and a financial 
transaction server; 

atthe server, accepting an account number and 
an identification number for the particular ac- 
count holder; 

atthe server, accepting the predicted transac- 
tion amount; 

atthe server, producing the transaction signa- 
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50. The method of claim 49.. including prompting the 
particular account holder to supply a combination 

of digits from a personal identification code., wherein 5 
the combination does not include all of the personal 
identification code. 

51. The method of claim 45, wherein establishing an 
authorization record includes: 10 

establishing a communication session between 
a party to the particulartransaction and a finan- 
cial transaction server; 

at the server, accepting the presented transac- is 
tion signature and the actual transaction 
amount. 

52. The method of claim 51 , including accepting identi- 
fication of the party at the server. 20 

53. The method of claim 52, including maintaining a list 
of authorized parties, and wherein said matching in- 
cludes determining whether the identification of the 
party indicates a party in the list of authorized par- 25 
ties. 

54. The method of claim 51 , wherein said establishing 
an authorization record does not require identifica- 
tion of the particular account holder. 30 

55. The method of claim 45, wherein establishing an 
authentication record includes: 

establishing a communication session between 35 
the particular account holder and a financial 
transaction server; 
accepting an account number; 
prompting the particular account holder to sup- 
ply a static identification number and a dynam- 40 
ically identified combination of digits from a per- 
sonal identification code, wherein the combina- 
tion does not include all of the personal identi- 
fication code; 

accepting the predicted transaction amount; 45 
producing the transaction signature and send- 
ing the transaction signature to the particular 
account holder. 
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